https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# harvester
a
This message was deleted.
b
I do not see any public announcement from Harvester regarding this.
a
Yep, that’s exactly what I'm concerned about. Harvester is indeed affected by this CVE, and we need to find a way to patch our cluster. So far, the only workaround we’ve found is to manually disable the vulnerable KVM features. While this is fine for us since we don’t use them, assessing the long-term impact of this change is difficult, and it will be hard to maintain over time. I’ll open an issue on GitHub to get more visibility on their official patch management plans for this.
p
afaik nested virt has never been supported in Harvester. it's not enabled by default. so you're not going to be vulnerable unless you've specifically enabled an unsupported feature for untrusted guests?github.com/harvester/harvester/issues/5243
l
Hiya, thanks for these questions & bringing up the concern of transparency wrt Kernel-based CVE disclosure & fixing. I've raised this internally and expect to hear back soon on how we plan to manage these in future. Thank you for your patience!
FWIW, for the above CVE, we're already working on fixes and are awaiting a kernel patch that will be included in v1.8.2. The only possible workaround, as suggested above, would be to disable the nested virtualisation by disabling the option in the kernel module. This requires rebooting the hosts.
a
Thank you Divya. If community needs it, here is the cloudinit we are pushing before restarting all nodes:
Copy code
apiVersion: <http://node.harvesterhci.io/v1beta1|node.harvesterhci.io/v1beta1>
kind: CloudInit
metadata:
  name: cve-2026-53359-januscape
spec:
  matchSelector:
    <http://harvesterhci.io/managed|harvesterhci.io/managed>: "true"
  filename: 66_cve-2026-53359.yaml
  contents: |
    name: "Mitigate CVE-2026-53359 (Januscape)"
    stages:
      boot:
        - name: "Disable KVM nested virtualization via kernel cmdline (kvm_amd.nested=0)"
          commands:
            - |
              GRUBENV=/oem/grubenv
              ARG="kvm_amd.nested=0"
              cur=$(grub2-editenv "$GRUBENV" list | sed -n 's/^third_party_kernel_args=//p')
              case " $cur " in
                *" $ARG "*) : "already present, nothing to do" ;;
                *) grub2-editenv "$GRUBENV" set third_party_kernel_args="${cur:+$cur }$ARG" ;;
              esac
🙌 2
m
@ambitious-addition-71545 thanks for bringing this up, we will have a kb article for this ready soon, while qa is verifying the workaround
🙌 2
p
where is the evidence this affects guests w/o nested virt? > The key here is nested virtualization. When a guest (L1) itself becomes a hypervisor and runs another guest (L2) inside it with EPT/NPT, the hardware two-stage paging has only one stage, so L0 (the host) must shadow in software the EPT/NPT that L1 built for L2. Because this nested EPT/NPT shadowing shadows page tables controlled by the guest, it goes through the legacy shadow MMU rather than the TDP MMU. This bug lies exactly in that process where the shadow MMU shadows guest page tables. > Another important point is that all of this happens inside in-kernel KVM. The faults that occur as L1 builds its own nested EPT and runs L2 are all handled by the host kernel KVM and never leave to a userspace VMM (such as QEMU). This bug is therefore a pure kernel KVM bug unrelated to QEMU emulation. github.com/V4bel/Januscape/blob/…/write-up.md
m
i thought nested virtualization is one of the key conditions for the exploit
or did you mean evidence that this does not affect guests w/o nested virt
a
I think it is about this note in the KB
Copy code
NOTE: Even x86_64 systems not used as KVM host may be affected.If either module of kvm_intel or kvm_amd are loaded a attacker might be able to gain privileges.This can be mitigated by blacklisting the kvm modules:
👆 1
m
that's from the more generic support article, not the harvester one, and it looks a bit incomplete to me
i need to check with the support team who submitted that article
but i have a feeling they are referring to the case where the 
/dev/kvm
device is world-accessible
meaning unprivileged user can open the device, spin up a throwaway vm (even though the host isn't used as a kvm host), and trigger the exploit
p
hm yeah I mean if you allow an unprivileged user to write arbitrary Harvester VM YAML, that seems likely to allow a lot of exploits unless extremely careful somehow
at least according to claude, it's only if you enabled nested virt. so we have done like 
spec:
domain:
cpu:
model: host-passthrough
Then on AMD you can see 
cat /proc/cpuinfo | grep svm
- on a default Harvester VM though that's blank, there's no nested virt and it's not exploitable. > Running an L2 is impossible unless the L1 guest can see the vmx (Intel) / svm (AMD) CPU feature flag. That exposure is gated entirely by the per-VM CPU configuration, and the metal-level kvm_intel nested=1 setting does nothing on its own to > grant it: > > - host-passthrough → exposes vmx/svm (and everything else). > - host-model → does not reliably expose vmx/svm; the toolstack deliberately treats nested as a special case, so you generally still need the feature added explicitly. > - custom (libvirt's default when no mode is given) → standard named/QEMU CPU models do not carry vmx/svm unless you add feature name='vmx' policy='require'/. this aligns with what we found when specifically trying to enabled nested virt also. host-passthrough was necessary to get it reliably
m
i think i see what you mean about host-passthrough, but in the context of januscape, aiui, it shouldn't affect the mitigation steps, right? or what am i missing? atm, harvester doesn't fully support nested virtualization - would love to have your inputs when we start tackling that story
as for the note on non-kvm hosts being affected (which came from this kb), iirc what we are saying here is the info isn't correct (or at least, imo incomplete), right? again, i suspect they are referring to the more generic case with the overly opened permissions on 
/dev/kvm
, but w/o offering more context, it's a bit misleading - i can find out which team posted that and get them to update it
p
Harvester definitely supports nested virtualization, just not via the UI. but I've always seen it as risky and only enabled for trusted guests / single tenant metal nodes. it is very useful. but yeah that kb doesn't seem super-applicable to Harvester case. imo it's like "if you knew you wanted nested-virt enough to handle the risks and trouble of enabling it for your Harvester VMs before, maybe do a reassess on that now. and/or if you allow writing arbitrary untrusted VM YAML into Harvester"
13 Views
Open in Slack
PreviousNext
Powered by